home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19961006-19970104 / 000003_news@columbia.edu _Sun Oct 6 22:59:53 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id WAA00431 for <kermit.misc@watsun.cc.columbia.edu>; Sun, 6 Oct 1996 22:59:53 -0400 (EDT)
  3. Received: (from news@localhost) by newsmaster.cc.columbia.edu (8.7.5/8.7.3) id WAA20226 for kermit.misc@watsun; Sun, 6 Oct 1996 22:59:51 -0400 (EDT)
  4. Path: news.columbia.edu!panix!newsfeed.internetmci.com!feed1.news.erols.com!howland.erols.net!agate!info.ucla.edu!unixg.ubc.ca!alph02.triumf.ca!shoppa
  5. From: shoppa@alph02.triumf.ca (Tim Shoppa)
  6. Newsgroups: comp.protocols.kermit.misc
  7. Subject: Re: Line noise stats in C-Kermit ??
  8. Date: 7 Oct 1996 02:59:43 GMT
  9. Organization: Tri-University Meson Facility
  10. Lines: 35
  11. Message-ID: <539rmv$rft@nntp.ucs.ubc.ca>
  12. References: <CROTEN.96Oct6165005@big.aa.net>
  13. NNTP-Posting-Host: alph02.triumf.ca
  14.  
  15. In article <CROTEN.96Oct6165005@big.aa.net>,
  16. Charles Roten <croten@big.aa.net> wrote:
  17. >But this brings up another issue .. the status of my local telco's 
  18. >lines.  They are now a matter for suspicion.  
  19. >
  20. >I found nothing in the C-Kermit book, or in Kermit News, about a way 
  21. >to use Kermit to troubleshoot lines.  Something like a log of line 
  22. >problems, or a "line integrity check" mode that would bounce packets 
  23. >back and forth across the chosen transmission line, and keep records 
  24. >of the lossage and symptoms.  
  25.  
  26. In the days of 300/1200/2400 baud modems without error correction,
  27. the scheme you are proposing could be worthwhile.  But with modern
  28. error correcting modems, there are so many layers buffering
  29. the data between both ends that a determination of line
  30. quality by observing the data to/from the modem can be very, 
  31. very difficult.  The connection tends to either work or drop.
  32. And when the connection drops, I find that the cause is more likely
  33. a bug in the modem's firmware or a negotiation incompatibility
  34. between the two modems - though certainly marginal line conditions can
  35. make things worse.
  36.  
  37. Most modems today can be told to disable error
  38. correction and compression, and this would be the place to
  39. start doing what you propose.  It would also be wise to figure
  40. out how to "lock" both modems into some specific rate before
  41. performing such tests.
  42.  
  43. On the other hand, many of the best modems available today can
  44. report error/retry statistics through AT-style command packets.
  45. Some of the really top notch external modems have LCD displays
  46. on the front that display such information.  Needless to say,
  47. you won't find any of these features on RPI modems...
  48.  
  49. Tim. (shoppa@triumf.ca)